Module for a switcher game

ABSTRACT

A software module for use in at least one computer game, is configured in use to run on a processor, wherein the at least one module comprises at least one component configured to provide a game function wherein said at least one component is configured to be controlled by at least one parameter the game function provided by said at least one component being determined by the at least one parameter.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on, and claims priority to, GB Application No.1304442.5, filed Mar. 12, 2013 and PCT Application No.PCT/EP2013/069289, filed Sep. 17, 2013, and is a continuation-in-part ofU.S. application Ser. No. 14/029,318, filed Sep. 17, 2013, the entirecontents of each of which being fully incorporated herein by reference.

BACKGROUND

Computer implemented games is a well-known category of games that allowa player to interact with a computing device to cause the processor toperform certain calculations and typically display a result on a screenor other display device.

Different types of games have evolved from classical arcade games in togames that can be played on a handheld device such as a smartphone orpersonal computer. Some games are also connected to the Internet and theplayer can play against or compare score with other users in multiplayermode.

A common genre of casual games is so-called ‘match-3’ games. This is atype of tile-matching game where the player manipulates tiles or gameobjects in order to make them disappear according to a matchingcriterion. In many tile-matching games, that criterion is to place agiven number of tiles of the same type so that they adjoin each other.That number is often three, and the corresponding subset oftile-matching games is referred to as ‘match-three games’. The criterionfor matching is often to place the tiles so that a number of tiles ofthe same colour or of the same shape or any other characteristic arealigned or adjoined.

Games have previously been developed and programmed on an individualbasis with all or most elements being built up specifically for thatgame. Our approach uses the model-view-controller (MVC) softwarearchitecture pattern to facilitate the creation of games of a specifictype. MVC separates the representation of information from the user'sinteraction with it. This can be implemented in several ways, some ofwhich are already known.

This approach drastically simplifies the way games can be built and alsoenhances the quality of the games created using this approach sincefewer parts of the game have to be recreated for each new game of thesame or similar type.

DISCUSSION OF RELATED ART

Casual social games have been implemented before and are known. Howeverprevious inventions have not successfully devised effective solutions tocreate games using a modular approach.

SUMMARY

According to a first aspect there is provided a method of designingmultiple computer games, using a software module running on a processor,in which the module enables pre-defined kinds of game design functionsto be implemented across multiple different computer games; and in whichthe module implements multiple pre-defined kinds of common game designfunctions; and is extensible in that new components can be added to themodule to create new functionality.

The module may use a Model View Controller (MVC) software architecturepattern.

The MVC may use entities, and enables components to be combined tocreate new entities.

The common game design functions may include generating a game board ofdefined size and layout.

The common game design functions may include game rules or game-playlogic, such as switching objects, matching objects, removing objects,and generating objects.

The common game design functions may include all of switching objects,matching objects, removing objects, and generating objects.

The common game design functions may include common game rules.

The module may allow new game rules to be designed and included withinthe module.

The common game design functions may include creating new game levels.

The module may enable debug tracking data to be stored, such as storingthe board state, history of all moves.

The module may receive events that trigger the game logic to beprocessed and then fires off new events that can be used to drawgraphics.

The method may include the step of: using data analytics to understandthe impact of changes to the game design in terms of player engagementand/or monetisation and implementing changes to the game design,including frequent changes such as daily or weekly changes, to optimiseplayer engagement and/or monetisation.

The method may include the step of deploying multiple different computergames on a game playing web site hosting a large number of computergames, the games each including the software module; using dataanalytics to measure player engagement and/or monetisation of a game;for games that provide sufficiently high levels of player engagementand/or monetisation, migrating those games to a platform that supportsmobile game play on smartphones, tablets and also PCs.

The method may, for games that provide sufficiently high levels ofplayer engagement and/or monetisation, the further step of using thesoftware module to add extra game play levels and additional game designfunctions.

The method may include the step of using the software module toregularly add extra game play levels and additional game designfunctions, potentially indefinitely.

The method may be used to enable social casual games to be rapidlycreated and revised.

The method may be used to enable switcher games to be rapidly createdand revised.

The method may be used to enable match-3 games to be rapidly created andrevised.

The method may be used to enable clicker games to be rapidly created andrevised.

According to a second aspect there is provided a software module for usein at least one computer game, configured in use to run on a processor,wherein the at least one module comprises at least one componentconfigured to provide a game function wherein said at least onecomponent is configured to be controlled by at least one parameter thegame function provided by said at least one component being determinedby the at least one parameter.

The module may be configured to cause at least one component to be usedin one or more levels of the at least one computer game.

The game function may comprise at least one game element.

The at least one parameter may be configured to control at least one offunctionality, behaviour and characteristics of said at least one gameelement.

The game function may comprise a game board.

The at least one parameter may be configured to control at least one ofsize and layout of the game board.

The game function may comprise at least one game rule.

The at least one game rules may comprise at least one of: switchingobjects; matching objects; removing objects; and generating objectswherein said at least one parameter is configured to control at leastone of the effect of the game rules and conditions for game rules to beapplied.

The at least one parameter may be configured to control at least one ofthe effect of the game rules and conditions for game rules to beapplied.

The module may be configured to store debug tracking data for componentsof said module.

According to third aspect there is provided a method of designing atleast one computer game using the module as described above.

The method may comprise using at least one component of said module inat least two different game levels.

According to another aspect, there is provided a computing devicecomprising a model module, said module configured in use to run on aprocessor, wherein the at least one module comprises at least onecomponent configured to provide a game function wherein said at leastone component is configured to be controlled by at least one parameterthe game function provided by said at least one component beingdetermined by the at least one parameter.

The computing device may comprise a view module.

The computing device may comprise a controller module.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic illustration of a computing device.

FIG. 2 shows an exemplary environment.

FIG. 3 shows an example of a typical MVC software architecture.

FIG. 4 shows an example of a ‘match-3’ switcher game.

FIG. 5 shows an example of a ‘match-3’ switcher game.

FIG. 6 shows an implementation of a virtual map.

FIG. 7 shows a schematic layout of a user device

FIG. 8 shows an example model module.

DETAILED DESCRIPTION

The present invention relates to a software architecture module that canbe used when creating a game. The following description will use a‘switcher’ game as an example of a typical implementation of the module.It is however understood that the invention can be implemented for othertypes of game such as ‘clicker’ and ‘bubble shooter’ games.

In the following description of various implementations of theinvention, reference is made to the accompanying drawings which form apart thereof, and in which is shown by way of illustration variousimplementations in which the invention may be utilized. It is to beunderstood that other implementations may be utilized, and structuraland functional modifications may be made without departing from thescope of the present invention.

The terms user and player are used interchangeably throughout thisdocument and no specific meaning is intended using one or the otherunless the context suggests otherwise.

FIG. 1 shows a schematic picture of a computing device, containing aCentral Processing Unit and Random Access Memory. The CPU acts accordingto input given from input devices, such as a keyboard, mouse ortouchscreen. Computer BUSes are used to communicate, both between inputdevices and the CPU, but also between different controllers within thecomputer device, such as the graphics controller and the networkcontroller. These controllers in turn communicate with external devices,such as a monitor for video output with which the graphics controllercommunicates, and the network controller communicates with for instancethe internet, through wireless or wired connections. A user can interactwith the computing device through input devices, such as a pointingdevice (e.g. a mouse) and a keyboard. The computing device can bestatic, for example a desktop computer, or mobile for example a laptopcomputer, a tablet or a mobile phone. The computing device can run anoperating system typically associated with desktop computers, forexample Windows, OSX or Linux-based operating systems, or a mobileoperating, for example iOS, android or windows phone. The CPU may beoperated to load an application into the RAM and run the application.The application may be a game. Alternatively, the application may be aweb browser which can be operated to load and run a game program.

FIG. 2 portrays an exemplary overall environment in which the presentinvention may be utilized. A virtual game is stored on for instance agame server 210. The virtual game is to be played on a client device,such as a computer 240, 250 or a smartphone or other handheld device260. The client device can also be a kiosk, arcade gaming station, smartTV or other device with computing capabilities, input devices and ascreen that can present the game to a user. The client devicecommunicates with a game server 210 and a social network server 230, forinstance through the Internet 220 or other network. It should beunderstood that the social network 230 and the game server 210 does nothave to be located in different places, they could be on the same serveror on a plurality of servers located in different locations. Peopleskilled in the art will understand that other devices than the exemplaryones listed can be also be used without departing from the spirit andscope of the invention.

The techniques described in this patent may be deployed in manydifferent gameplay architectures. For example, a computer game may beimplemented as a computer program that is stored and runs entirelylocally on the processor of a PC, games console, tablet or mobiletelephone or other computing device. The game can be implemented solelyas a computer program that is stored and runs entirely on one of manyprocessors in a remote server, and data streams or updates are suppliedto the client device (e.g. tablet, smartphone etc.) to enable the clientto render and display graphics and sounds; this ‘web services’ approachis increasingly common.

Another approach is a hybrid one, in which back-end servers handle someelements of the gameplay, and for instance a Java game applet isprovided to client devices and it is the locally running Java appletthat generates the graphics/sounds/user interaction for gameplay on theplayer's client device. Some data may be fed back to the back-endservers to enable scoring, interaction with other players andcross-platform synchronisation. Generally, the techniques described inthis specification are not specific to any one game architecture but canbe deployed on any suitable game architecture.

The game created using the techniques disclosed herein may beimplemented allowing a user to interact with it in different waysdepending on the capabilities of the device which the user is accessingthe game with. A user can interact with the game through using a touchscreen where the user can select and/or move elements on the game boardwith a finger or for instance with a stylus. The game can also be playedwith a pointing device such as a mouse or other interaction devices suchas a keyboard.

Mobile devices may have a touch screen interface where the player caninteract with the game using a finger or a pointing device such as astylus. Some mobile devices have hard keys that complement the touchscreen interface. Such hard keys may be in the form of a button or inthe form of a joystick type of interaction.

Over the course of players playing the game, data will be produced. Thisdata can for instance be related to a player's game performance or togame information related to a social network to which the game isconnected. It is possible to gather this data, store it and make use ofit for instance to improve the game. One example is by using a databaseto store the amount of times players try and fail a level on average.This data can then be reviewed, and if the players seem to fail asubstantial amount of times before completing a level, the difficultycan be adjusted accordingly. The difficulty can be adjusted throughchanging a score target for the level, increasing the available time ormoves or giving the player for instance a booster to enhance thegameplay.

There can be certain performance indicators used to measure the successof the game. These indicators can for instance relate to playerretention, the virality of the game and the revenue of the game.

A person skilled in the art will realise that the different approachesto implementing the game is not exhaustive, what is described herein arecertain preferred embodiments. It is possible to implement the way in anumber of variations without departing from the spirit or scope of theinvention.

In a typical match-3 switcher game different game elements are swappedwith each other to make moves on a game board. FIG. 4, FIG. 5 showexemplary implementations of a match-3 game. To gain points the playerhas to make moves that create matches of at least three of the samecandy. If doing so, the player gains points and the matched candies areremoved from the game board. As a result, new candies fall into placefrom the top of the game board in order to fill any empty spacescreated. For all candies that are removed on the game board, points maybe shown in the same colour as the candy that was removed, for examplethree red candies will show red points, green candies green points andso on. If a blocker element would be removed then the points shown wouldbe in the same colour as the candies from the match that removed it.

Only swapping moves that will create at least one combination of atleast three game elements of the same type are allowed.

If the player makes a match of more than 3 elements certain other newelements may appear on the game board. For instance in a typical match-3switcher game a combination of four game elements may generate a specialgame element that if combined will remove one whole row or column on thegame board. A combination of five game elements may generate a specialgame element that removes all game elements of a certain type ifincluded in a match of game elements of that type.

A typical game mode of a match-3 switcher game provides the player witha limited number of moves to reach the level target.

Specifically in computer games and game engines, an entity is a dynamicobject such as a non-player character or item. The invention can bereferred to as a part of an entity system where components are used toform a whole.

The game module covers the game play of a computer game. The game moduletypically does not cover server communication, level progression andsocial network integration.

The switcher game module plays the part of the basic model for anyswitcher game, for example, common notions in switcher games such asswitching objects every turn, matching same items, etc., are handled bythe module.

Key aspects of a switcher game can be to have a board of x height and ywidth, elements on the board that need to be matched, matching patternsto match those elements, removal of elements when matched, elementgeneration and randomization, game rules.

In a most basic implementation, a game development team would take theswitcher module, add classes to handle drawing graphics and some datafiles to define their board elements and they would have a workingswitcher game.

The module receives events that trigger the game logic to be processedand fires off new events that can be used to draw the graphics.Practically, the game team would need to add game specific features tomake their game unique, but having the switcher module would give a verybig advantage since it would provide them with a big chunk of the codeneeded for free. Another advantage is that it was designed with that inmind, so there should be minimal effort in understanding it andimplementing the visuals and adding the game specific features.

The game module can be used for games that are designed to workstand-alone and for games that for instance require a connection to asocial network.

The module may in some implementations have functions that generally areused by a switcher game. For instance, a module for a switcher game caninclude the following functions:

-   -   Generating a board of variable size to play the game on. It        provides different generators for that purpose (random, fixed,        mode-specific) and can easily be extended with more.    -   Common switcher game-play logic. All switcher games need to        switch elements, match them, remove them when matched, add new        ones to replace the removed one, shuffle when there are no        moves. The switcher module handles all this.    -   Common game rules. A switcher game will end under various        conditions such as no moves left, score achieved, specific items        collected. The module handles these basic rule cases and allows        them to be extended with more.    -   When something goes wrong in a game, it is great if the        developers have debug information (such as the board state, the        switch made, etc.) in order to fix the issue. The module        provides all that.    -   A structure that we call entity system that allows us to create        new types of elements for the game by combining components. For        example, if you need an element that can be matched and creates        an explosion, you create a matchable and an explosion component.        If you need an element that can be matched and does not move,        you reuse the matchable component and add an unmovable        component. The module has a variety of such components and        allows for the easy addition of new ones.    -   A level editor that is used for creating levels.

Examples of specific commands that may be used in the switcher are:

-   -   Prepare game—A command for preparing the game so that it can be        played.    -   Prepare board generator—A command for activating a generator for        generating a playing board.    -   Prepare tunnels—A command for creating tunnels.    -   Handle board create failed—A command for handling cases when the        board generation has failed    -   Ensure no board selection—A command for ensuring nothing is        selected on the board    -   Set possible swaps—A command for determining the swaps that it        is possible to make.    -   Handle board object dragged—A command for determining what        happens when an object on the board is dragged.    -   Handle board object clicked—A command for determining what        happens when an object on the board is clicked.    -   Apply match effects—A command for executing what happens when        objects are matched.    -   Decrement moves until drop down item is spawned.    -   Update item target progress—A command for updating the target        objects to match.    -   Add score from matches—A command for adding scores from a match        to, for instance, a top list.    -   Reset score multiplier—A command for resetting a multiplier for        the player's score.    -   Check collectible items—A command for checking for collectible        items.    -   Award collection score—A command for awarding a player for        collecting items.    -   Remove destructibles—A command for removing objects that can be        destroyed.    -   Apply remove effects—A command applying relevant effect after an        object is removed.    -   Handle player move ended—A command for determining what happens        when a player makes a move    -   Handle shuffle failed—A command for determining what happens        when a shuffle does not generate any possible moves.    -   Select booster effect tile—A command for choosing where the        effect a booster will happen.    -   Select booster—A command for selecting a booster.    -   Unselect booster—A command for de-selecting a booster that has        been selected.    -   Use boosters that should be used instantly—A command for using        boosters that give an instantaneous effect.    -   Use booster—A command for using a booster.    -   Try swap items—A command for swapping items.    -   End swap items—A command for triggering events supposed to        happen after a swap    -   Drop floating items—A command for dropping items in empty spots        underneath them.    -   Fill empty tiles with random items—A command for filling empty        tiles in the game with randomized items.    -   Remove matched items—A command for removing matched items.    -   Board model—Holds information about the state of the board and        the objects on it.    -   Pass processor—Processes the board after a match.    -   Pass terminator—Handles the condition after a pass will        terminate.    -   Start—Starting the pass processor.    -   Make pass—Making one pass with the processor.

In addition to dividing the application into three kinds of components,the MVC design defines the interactions between them. FIG. 3 shows anexample of a typical MVC software architecture.

A controller can send commands to its associated view to change theview's presentation of the model (e.g., by scrolling through adocument). It can also send commands to the model to update the model'sstate (e.g., editing a document).

A model notifies its associated views and controllers when there hasbeen a change in its state. This notification allows the views toproduce updated output, and the controllers to change the available setof commands. A passive implementation of MVC omits these notifications,because the application does not require them or the software platformdoes not support them.

A view requests from the model the information that it needs to generatean output representation.

The controller module handles the user input to the device. A controlleris configured to receive input signals and convert the signals intocommands to be sent to the model module. The module stores the currentstate of the game and is configured to receive the commands and processthem according to the rules of the game. The view is configured to pollthe model for information related to the state of the game allowing thedisplay output to be updated.

There is usually a kind of hierarchy in the MVC pattern. The Model onlyknows about itself. That is, the source code of the Model has noreferences to either the View or Controller.

The View, however, knows about the Model. It will poll the Model aboutthe state, to know what to draw. That way, the View can draw somethingthat is based on what the Model has done. But the View knows nothingabout the Controller.

The Controller knows about both the Model and the View. To take anexample from a game: If you click on the “fire” button on the mouse, theController knows what fire function in the Model to call. If you pressthe button for switching between first and third person, the Controllerknows what function in the View to call to request the display change.

The reason to keep it this way is to minimize dependencies. No matterhow the View class is modified, the Model will still work. Even if thesystem is moved from Windows to an app in a smart phone, the Model canbe moved with no changes. However, the View and the Controller probablyneed to be updated.

Accordingly, in some embodiments, a model module can be designed for aspecific game and have an interface specific to that game. The interfacemay be more abstract and may be a generic interface for a genre ofgames, for example a match-3 switcher interface. A controller can beconfigured to communicate with the model module through the interface.There may be a different controller module for use in each targetoperating system. For example, a controller module may be configured toreceive input information on a mobile device running Android and anothercontroller module may be configured to receive input information from aweb browser. If the interface to the model module is abstracted, thecontroller module may be re-used for another game in the same genre.

A library of components may be produced for use by developers. Thislibrary may be built up through the development of games to allow there-use of components in other games. For example, in a match-3 switchergame, matching three elements of a particular type may create an effect.For example, matching three elements of a type may cause the surroundingelements to be destroyed via an explosion. The mechanics of theexplosion may be stored in a library to be re-used in later games oralternatively may be re-used in a different aspect of the same game. Forexample, the explosion mechanic may then be used in connection with anitem that allows a player to select a target location where theexplosion may be used to destroy nearby elements. In the example, theexplosion caused by the item may use different or the same graphicalresources which are provided by the view module. In this way, theprogrammer may ensure the component when first developed is easilyapplicable later on in development. In subsequent uses of the samecomponent, large time savings can be achieved.

The MVC model can be used to aid multiplatform design. A library ofinput and output components may be readily combined to create acontroller module or a view module for a particular platform. These maybe re-used to allow faster development of a controller module or viewmodule when developing a later game.

An example from the production of King's game Farm Heroes Saga will beused to showcase the strength of the system. Sometime midway duringproduction, a new element for the game called ‘Fount’ was implemented.The Fount should be destroyed after a match of other elements was donenext to it 3 times.

In a different architecture, a developer would need to write new logicthat does all this. Without the entity system, that could take anythingfrom 1 to 2 weeks for one developer. Having the entity system, it ispossible to reuse components that were created for other types ofelements. For example, the ‘destructible’ component with health 3 wasused to implement the part when the fount is destroyed after nextmatches next to it. The fact that the matches need to be next to it andnot on it or on the other side of the board was taken care by settingthe already existed attribute “from Outline” to true. The whole featurewas done in pretty much a day or two by adding code for the visuals andvery few lines of logic code.

The other side of this being extensible is that the module itself wasmade to be reused. Any game that uses it is by definition an extensionof the module. It is architected so that it makes it easy to either usethe existing functionality or override parts of it at will to implementslightly or vastly different game behaviour.

Working with badly structured code is a problem for developers. Suchcode is hard to understand, hard to extend and extremely expensive tomaintain in the long run. Also, it is preferable to reuse as much aspossible when creating new code, so as to avoid unnecessary work. AModel View Controller based approach makes this possible.

Another issue that most game code bases have is a distinct lack of unittests. Unit tests are the proof that the code works as intended. Inorder for code to be reused and trusted by other developers, it needs tobe extensively covered with unit tests.

Games created using the invention described herein can be connected toor linked with a social network such as Facebook™ or Google+™ or a gamesplatform with different players who can interact and see each other'sprogress. It is common that the users on such networks have avatars withfor instance a photo of the user and/or the user's name Such avatars canfor instance also be a sign or a figure.

The social network can be located on a server that is different from theserver on which the game is located, the game and the social network canalso be located on the same server. In some implementations there is adirect live connection between the social network and the game platformthat continuously synchronise them, in other implementations the twoplatforms synchronise at certain intervals, such as when the player logsinto the game. The players progress when having played in offline mode(for instance completed levels and score), for instance if the player istravelling in a tunnel, can be synchronized when the player is connectedto the internet.

The user and his friends' avatars can be displayed in the game or inrelation to different levels in the game to show the player's progress.The avatars can also be shown in relation to indicators of the player'sskill level or high score. In some implementations the avatars can bederived from a social network to which the game is connected, in otherimplementations they can be derived from a database related to the game.It is possible for the avatars related to users to change depending onthe overall progress or performance in the game. For instance, an avatarcan become larger or more visually advanced as the player plays the gamefor a longer time.

The user can connect with other users of the social network, either as“friends” on the social network or as “friends” within the gameenvironment. The player can interact with other players he is connectedto on the social network or who are playing the same game.

The game can be implemented to synchronize game state information and/orretrieve and connect to the social graph information and user profile ofthe player on a social network. It can also be connected to aproprietary network related to the game or the game developer.

The game can also be implemented so that it is connected to a pluralityof social networks. The user can be given the option to select whatinformation that can be derived and shared with which social network.

One example of how the game can be connected to a social network is theFacebook™'s Open Graph API allows websites and applications to draw andshare information about more objects than simply people, includingphotos, events, and pages, and their relationships between each other.This expands the social graph concept to more than just relationshipsbetween individuals and instead applies it to virtual non-human objectsbetween individuals, as well. A game can typically share in-game eventssuch as that a level has been completed, that a player has passed afriend in the game or beaten a friend's high score on a level. The gamecan also post events, such as that a player has purchased objects in thegame or received objects from other players of the game.

These social networking features can be stored in a component library.For example, a component may be used to interact over a socialnetworking API with a social networking server. The component mayrequest a list of contacts from the server which may be provided to theuser device. The list of contacts may be ordered and displayed by acomponent in the view module. In this example a component for fetchingsocial networking data can be re-used in the model module of any gamerequiring this feature. A corresponding component in the view module canbe added to poll the model module for the data and produce a graphicalrepresentation on the display.

One way of implementing a game using the techniques described herein isthrough a web site with a plurality of casual games. This platform canbe used as a basis to test the performance of the game and how it isperceived by players. In some web-based implementations the game isimplemented to be played in head-to-head tournaments, has a limitednumber of levels and no external social network connection. In someimplementations the players can play the game against other players onthe platform.

If a game proves to be successful in a web-based implementation, it canbe further adapted to another type of implementation, based on a virtualterrain in which the player progresses. This implementation typicallyhas a connection to an external social network, and can have multiplegame modes such as asynchronous and synchronous tournaments and singleplayer mode. The nodes on the map in the game are typically differentlevels that the player can play.

The two implementations described above can be part of a modularizedapproach to developing games, which help streamline and facilitate theprocess of producing as well as further developing new titles.

The game can be implemented so that a player progresses through multiplelevels of changing and typically increasing difficulty. FIG. 6 shows animplementation of the game with a virtual map layout of a gameenvironment, displayed on the screen of the computing device used by thegame player. As the player progresses through the levels in the game,his progress is represented as a journey along a path on the virtualmap. Representing progress in this manner provides an additional layerof engagement for players, and also opportunities for viralisation andmonetisation.

The virtual map consists of stages 1, 2 with varying number of levels 3,4 represented by nodes on the virtual map. The user travels betweenlevels and completes the levels one by one along a path by playing theassociated game. When the player reaches the goal of a level, the nextlevel on the path is unlocked and the player can play that level in thegame. The number of stages and levels can vary depending on theimplementation.

In some implementations of the game, the player will be introduced tothe game by tutorials explaining the fundamentals of the game. One wayof doing tutorials is to force the player to make certain moves, forinstance in the first level of a game the player might be prompted tomake the most basic move possible without the option of doing any othermove. The tutorials will in most cases be concentrated to the firstlevels of the game, but they can also be used at later stages to explainnewly introduced elements and objects.

The levels can be numbered consecutively throughout the game or they canbe numbered within a stage, it is also understood that other ways ofidentifying the stages and levels can be implemented. New stages to thevirtual map 12 can be added by the game designers at any time—so a gamemay be launched with say 20 levels, and after a number of weeks, theremay be fifty or sixty levels present.

Stages in the game can be both locked or unlocked. In mostimplementations, the majority of levels start out as locked and are thenunlocked as the player progresses in the game. Unlocked stages cantypically be replayed at any time. One way of unlocking new stages is tocomplete the last level on the latest stage. The user is sometimes facedwith other challenges to unlock the next stage in the virtual map.

In some implementations, certain levels and stages are locked based onother criteria than the player's linear progression in the game. Suchlevels can for instance be based on the total score the player hasachieved on all levels, the average performance on levels or on thenumber of friends that the player has invited to play the game.

In one implementation, one challenge 7 to unlock a stage arises whentraveling from one stage to another once all the levels have beencompleted in that stage. The levels in the stage to which the player istravelling is typically locked by default, and the player must unlockthem. This requires the help of for instance three friends. The playercan ask friends for help by sending an in-game message within the gameenvironment or for instance through a social network that the game isconnected to. The friends can already be playing the game and do nothave to be ‘new’ players, but they can be friends not already on thesame social network.

The player can also pay to get instant access to the locked stage. Thecurrency used for paying can vary between different implementations, forinstance it can be hard or soft currency, or it can be based on scoreachieved in the game. It is possible for the currency to be associatedwith a social network to which the game is connected, or it can beassociated with another platform related to the game. The player can usea combination of help from friend and payment to unlock the new stage.The cost for unlocking can in some implementations be lowered as afraction of the total number of friends needed when help from some butnot all needed friends have been received.

There can be ways of getting past a collaboration block other thanasking friends for help and paying for it, which are the most commonways of passing a collaboration block. This can be done through to useof ‘Mystery Quests’, which gives the player the option of completing oneor several challenges to unlock the block. Such challenge can forinstance be to play one or several past levels with modified goals inorder to pass the collaboration block, for instance three levels—one foreach of the locks.

These challenges are typically in the form of replaying a previouslycompleted level but with a new goal to reach, for instance a target highscore. In a typical implementation, the score requirement is higher thanit is for playing the level regularly, and also no other goals need tobe fulfilled. For example, if the player gets to replay a level withjelly with a new target high score, the player would not need to removethe amount of jellies specified as long as the target score was reached.

The request for help is sent to the friend who then has the option toaccept to help. The request for help can in some implementations be sentusing the social network to which the game is connected; an alternativeimplementation is to send the request to someone external to the game(via email, text message, instant message for instance) who has to jointhe game to respond to the help request. It can be understood that therecan be variations between implementations in regards to how playersrespond to requests from other players. In a typical implementation, alink will be provided to the player who has been requested to help. Thislink can be related to a social network to the game is connected. Thisis one of the viralisation techniques implemented in this game.

In addition to the virtual map layout in FIG. 6, there can also be otherlevels or stages that are not part of the progress along the path in thevirtual map. Such stages or levels can be present in the game associatedwith the virtual map at all times or can be unlocked when the userreaches a certain in-game achievement. This in-game achievement can forinstance be completing a specific level, reaching a predetermined highscore (for instance, collecting a specific number of stars whencompleting a level—highly skilled gameplay can win the user three stars)or paying virtual currency to unlock the stage or level.

The map layout in FIG. 6 can be used in games connected to or linkedwith a social network or in a game with a user database. It is possiblefor users to have an account in the game or on the social network. It iscommon that the users on such networks have avatars with for instance aphoto of the user and/or the user's name. Such avatars can also be asign or a figure. The user's avatar is displayed on the map layoutalongside the level where the user is 6. It is understood that there aredifferent implementations of showing where the user currently is on themap. This can for instance be the latest level the user completed, thelevel where the player has achieved the highest score or the lastcompleted level along the traversed path.

The user can in some embodiments be given the option to select whichusers should be shown on the virtual map. The users to choose from canbe friends on a social network, or the user can get suggestions to showfriends which meet a certain criteria, for instance friends which theplayer has interacted with the most in the past or friends living in thesame geographic area as the player. The user can get the option tochoose from other people not being friends on the social network, butthat meet other certain criteria.

The user can play any of the unlocked levels on the map, so the user cango back and replay already completed levels to get a better score orbeat friends' high scores.

The player is in some implementations of the game rewarded for goodgameplay of a level, for instance reaching a target score or completingthe level in a short time. In some implementations the user has to reacha certain number of points to complete a level, reaching this targetscore can be represented with a symbol such as a star. In oneimplementation a star is lit when the user reaches a certain number ofpoints in a level. The user can earn more than one star on each leveland the levels are re-playable to get a higher score. In someimplementations the indicators representing the players' performance canbe related to other goals, such as completing levels within a certainamount of tries.

The player's total number of stars collected in the game can in someembodiments unlock features. The unlocked features can for instance bepower-ups, in-game currency or bonus levels. After being unlocked, suchfeatures can typically be accessed by the player in the game. Someunlockables might be given to the player while others require a purchaseto be accessed.

The symbol representing how well the user has played on each level canbe displayed alongside the level on the map 8, 9, 10.

In the map view, the player can hover over an unlocked level to displaya thumbnail version of it. This makes it easier to find specific alreadycompleted levels, and can also give the player an idea of what to expectbefore actually starting a level. In a typical implementation,thumbnails cannot be displayed for levels that have not yet beenunlocked. If trying to view one of these a symbol of a padlock will bein the place the miniature version of the level is supposed to be.

The thumbnail can also display how well the player has done on the levelif he has played it previously. This can for instance be representedwith the number of stars the player has received on that level, theactual score or some other indication.

The thumbnail can also display the player's position on the high scoretable in relation to the player's friends or showing what friends are onthe high score table. This can be a driver for the player to replay thelevel to beat one of the friends.

If the game is connected to a social network or the user has connectedwith other players in the game, the levels can present a leaderboardshowing who among the user's connections, or among a subset of theuser's connections, that has the highest score. There can in someembodiments be a notification 11 shown on the map if the user that hasthe highest score among the friends connected to the game. Such anotification can be in the form of a message sent through for instancethrough the social network or an in-game message.

The type of game mode or game goals for a level can be displayed on themap as a symbol, for instance it can be a symbol for the level itself,or it can be shown in proximity to another symbol for the level. Such asymbol 3 can for instance be in the form of an object related to thegame goal, such as an hourglass representing a level with a timeconstraint.

In some embodiments, these features can be provided as building-blockcomponents that can drastically reduce the development time of gameswith this level of functionality.

The MVC pattern can be further applied to server side development. Agame may interact with a server to store and retrieve game progress. Theserver may store the user's progress information associated withmultiple games or alternatively just the one game. The server may have alimited view module, for example, configured to output a log and alimited controller module. The model module of a server may not varysignificantly between games. Accordingly re-using server modelcomponents may aid the development of subsequent server software.

The MVC pattern can further be used to aid the debugging of code duringdevelopment. The controller and view modules, which may be operatingsystem dependent, can be tested separately to the model module. Thetesting of the model module should operate the same regardless of theoperating system and can therefore be tested individually. It may be thecase that some operating systems have less sophisticated means fordebugging that are more time consuming and less user friendly. Forexample, debugging may be easier on a desktop computer than on a mobiledevice or a desktop computer emulating a mobile device. Accordingly,rigorous testing may be performed in the best debugging environmentrather than the need to perform full testing on each intended operatingsystem.

In some embodiments, components may be combined to create furthercomponents. For example, there may be a component which is destroyedafter three nearby matches and there may be a component that creates anexplosion effect when destroyed. A component could easily be createdwhich combined the two components to create an element which isdestroyed after three nearby matches causing an explosion effect.

In some embodiments, components may be customizable, accepting one ormore parameters. For example, the component which is destroyed afterthree nearby matches may be configured to be destroyed after any numberof nearby matches by accepting one or more parameters upon creation.

By creating library of configurable components that can be combined in alarge number of ways, creating a new game in the same genre may become amuch simpler task. In an example, a first match-3 switcher may use an8×8 grid of elements whilst a second match-3 switcher may use a 6×10grid of elements. The model module may be instantiated for the firstexample with the size of the grid as 8×8. An 8×8 match-3 switcher wouldbe produced. Alternatively, the model module may be instantiated with anargument specifying a 6×10 grid. Accordingly a new game may beinstantiated with a specific configuration without the need to redevelopnew software. In this way, a component can be arranged to accept one ormore input parameters. These parameters may affect the way a componentbehaves and may be chosen by a game designer or may be randomlygenerated or generated according to a set of rules. These parametersallow a new game to be designed using a similar selection of componentsto a previous game but with a different selection of input parameterswhich may result in a significantly different game. Similarly, a leveldesigner may design a level with a similar selection of components toanother level but provide a different choice of parameters which mayhave a significant effect on how the level plays or how difficult thelevel may be to complete.

The initial instantiation of a game can be combined with specific gamerules that can be introduced with pre-designed components to creature aunique game. These rules might set out general mechanics that arepresent across the whole game. In a game featuring multiple levels theremay be level specific mechanics or mechanics present on some but not alllevels.

The use of the MVC model can have advantages for level design in a game.In the example of a match-3 switcher, the level designer could imposerules on the types of elements present in the level. These rules couldbe stored in components and be reused and reconfigured. If a game isupdated, new functionality from new components can be added to new orexisting levels. It may be the case that two levels feature the samegame elements, for example in a match-3 switcher the starting positionof the elements may be the same, or the locations of various specialelements may be the same. These two levels could be made distinctthrough a component applying a particular rule to a level. This rulecould be for example, a rule might be a specific requirement to completea level or a change to the direction of gravity of a level. It may bethe case that for a particular game, the level design is entirely doneby choosing the rules for a specific level.

The view module is where a significant part of the new development workmay be required to make a new game according to some embodiments. Thecontrol and the model modules may be formed largely or entirely fromexisting components, with perhaps the need to develop some additionalcomponents. The view module of a new game may require new graphicalelements which may be required to distinguish a new game. Somecomponents may be re-used, for example a component for displaying socialnetworking information or a component for displaying elements of amatch-3 switcher game.

Reference is made to FIG. 7 which shows an embodiment of the presentapplication. A user device 701 is provided with an operating system 702,a graphical adapter 703, at least one input device 704 and a networkinterface controller 705. User device 701 is configured to run anapplication 706. Application 706 comprises a view module 708, acontroller module 709 and a model module 707. View module 708 isconfigured to poll model module 707 to receive game information. Viewmodule 708 is further configured to provide graphical information tographic adapter 703 which may be configured to display game informationon a display. Controller module 709 is configured to receive inputinformation from the at least one input device 704 and determinecommands to be sent to model module 707. In some embodiments, controllermodule 709 may send commands to view module 708. Model module 707 may beconfigured to communicate with network interface controller 705 whichmay have a network connection to server 711 via network 710.

Reference is made to FIG. 8 which shows a model module 801. Model module801 contains a module 803 which incorporates the features defining thegame. These features include any rules or functionality that is commonto all levels of the game. A plurality of modules 805, 807 and 809correspond to a plurality of levels of the game. Each of the pluralityof modules 805, 807 and 809 may contain at least one component 811, 813and 815. These components may comprise game rules specific to therespective level. These rules may be formed from a collection ofpre-defined game rules which may be combined and configured to produce aunique level. The components 811, 813 and 815 may be selected by a gamedesigner from a library of existing components. Some of the componentsmay be provided with one or more parameters which may affect thebehaviour of functionality of the components. In this way the designermay provide a combination of components and parameters creating a newgame or level from existing components.

1. A software module for use in at least one computer game, configured in use to run on a processor, wherein the at least one module comprises at least one component configured to provide a game function wherein said at least one component is configured to be controlled by at least one parameter the game function provided by said at least one component being determined by the at least one parameter.
 2. The module of claim 1 wherein the module is configured to cause at least one component to be used in one or more levels of the at least one computer game.
 3. The module of claim 1 wherein the game function comprises at least one game element.
 4. The module of claim 3, wherein said at least one parameter is configured to control at least one of functionality, behaviour and characteristics of said at least one game element.
 5. The module of claim 1 wherein the game function comprises a game board.
 6. The module of claim 5, wherein said at least one parameter is configured to control at least one of size and layout of the game board.
 7. The method of claim 1 wherein the game function comprises at least one game rule.
 8. The method of claim 7 wherein the at least one game rules comprise at least one of: switching objects; matching objects; removing objects; and generating objects.
 9. The method as claimed in claim 8, wherein said at least one parameter is configured to control at least one of the effect of the game rules and conditions for game rules to be applied.
 10. The module of claim 1 configured to store debug tracking data for components of said module.
 11. A method of designing at least one computer game using the module claim
 1. 12. The method of claim 11, comprising using at least one component of said module in at least two different game levels.
 13. A computing device comprising a model module, said module configured in use to run on a processor, wherein the at least one module comprises at least one component configured to provide a game function wherein said at least one component is configured to be controlled by at least one parameter, the game function provided by said at least one component being determined by the at least one parameter.
 14. A computing device as claimed in claim 13, further comprising a view module.
 15. A computing device as claimed in claim 13, further comprising a controller module. 